Embodiments described herein relate to methods for tag-grouping of blocks in storage devices, and storing control metadata in flash-memory systems.
Flash-memory systems have become very common in recent years. Due to certain characteristics of flash-memory devices, the handling of memory systems based on such devices is not trivial, and requires dedicated software to handle writing to and reading from these devices (thus, simplifying the use of the storage system for the user application). For example, NAND-type flash-memory is typically written (also called “programmed”) in chunks called “pages” (typically having the size of 512 bytes to 2K bytes). A flash page should not be written to unless the page is previously erased (i.e. all bits are set to “1”). However, erasing can only be done in chunks called “blocks”, with a block typically containing many pages. This significantly complicates the management of flash-memory devices, as data cannot simply be written into a random address without first making sure it is erased, but one cannot arbitrarily erase a target page as its neighboring pages sharing the same block might contain valuable data that should not be erased.
Another example of the complexities of using flash memory is the need for error correction. Flash-memory cells tend to have occasional errors when being read out. The storage system must provide appropriate mechanisms for correcting the data read out before returning the data to the requesting application.
In order to handle the above difficulties (and some others), it is common to access flash-memory systems through a software layer that takes care of all complexities, and provides the accessing application a simple-to-use “world view”. Such software layers are commonly called “flash management systems” (FMS) or “flash file systems” (FFS). Typically, such software executes within a flash controller dedicated to controlling and managing flash-memory devices, or within a host system accessing the flash-memory devices in which the software is part of a software driver servicing the storage system.
An FMS typically requires the storing of metadata (also called “control information” or “side information”) within the flash memory. Such data is essential for deciding on the right policies and activities to be employed by the FMS. A simple example is the storing of the erase count of each of the blocks in the storage system. Since there is a desire to level out the usage of blocks across the storage system (as blocks wear out with extended use), it is typical for an FMS to maintain, for each block, its number of accumulated erasure cycles, and use this data for deciding on the next block to be allocated for writing new incoming data. There are many more examples of metadata stored in flash-storage systems, some of them common to most systems, and others unique to specific storage systems that employ unique management algorithms. While the present disclosure discusses specific examples of metadata, it should be understood that the methods described herein are equally applicable to all types of metadata that are associated or used with flash-memory storage systems, as long as such metadata types comply with the conditions specified elsewhere in this disclosure as benefiting from the methods disclosed herein.
Many of the metadata types commonly used are block-specific. By block-specific, it is herein meant that the metadata provide some information that is a characteristic of the block as a whole. The above example of an erase count of a block is block-specific. As a block is the minimal unit of erasure, there is no point in providing an erase count for a single page. However, there are metadata types that are page-specific, in the sense that they provide information related only to a specific page, and different pages within the same block may have different metadata values. One common example for page-specific metadata is the error-correction parity bits typically stored with each page of user data to enable error correction when reading to the page. Obviously, the values of these parity bits depend on the specific data stored in a page, and therefore must be page-specific.
Block-specific metadata are much “cheaper” to handle in flash-memory systems than page-specific metadata. This is because block-specific data require just a single entry per block, while page-specific data require an entry per page. Since the number of pages is typically significantly higher than the number of blocks, the handling of page-specific metadata creates great difficulties for an FMS. The difficulties exist both in the need for more metadata space within the flash-memory devices, and in the need for larger amounts of RAM in the flash controller or host system (as the case may be) for storing tables of the metadata values for various pages.
Another example of page-specific metadata is metadata needed by some known methods for improving reading reliability in an FMS by adaptively adjusting the read reference voltages used for reading the flash-memory cells. In one such known method, the EMS keeps track of the adjusted read reference voltages successfully used for reading each page the last time the page was read. Those reference voltages are then used as a starting point the next time a page is read, thereby reducing the number of reading iterations in subsequent reading operations.
The stored last-used reference voltages provide another example of page-specific metadata. Even though all pages in a common block are erased at the same time, and typically have similar threshold-voltage drifting characteristics, their reference-voltage metadata values are not necessarily the same. This is because writing time is not necessarily common, even though erasing time must be common for all pages in a block. Typically, an FMS directs an incoming stream of consecutive, page write-requests into sequential pages in a block. If the stream of pages being written at a first point in time stops at a point that corresponds to a middle of a block, and then starts from there at a later point in time, then the same block would contain some pages written at the first point in time and some pages written at the second point in time.
In more complex scenarios, and depending on the specific algorithms of the FMS, a block might contain pages written at more than two points in time. In certain scenarios (e.g. when the files written to the device are not very large), it is even possible to have each page of a block written at a different point in time. If the host system writes pages at random addresses rather than sequentially, the result is even more likely to be many blocks with pages written at different points in time.
The amount of drifting of the threshold voltages of cells is strongly dependent on the time of writing. For example, a page written a year ago will typically have a significantly higher drift than a page written an hour ago. Drifting only starts after a page is written. Because of this, reference voltage metadata are considered page-specific metadata in a conventional FMS. As such, the handling of reference voltage metadata is subject to difficulties similar to those mentioned above, namely, extra space needed in the flash-memory devices and extra RAM needed in the flash controller or the host system. Accordingly, there is a need for improved handling of page-specific metadata.
In the prior art, methods are known for storing metadata in flash management systems that depend on the time of writing the data to which it is associated. U.S. patent application Ser. No. 12/102,063 by Lasser et al. (hereinafter referred to as Lasser '063) assigned to the assignee of the present disclosure, and incorporated by reference as if fully set forth herein, teaches such methods in which the metadata is stored on a per-page basis.
It would be desirable to have methods for tag-grouping of blocks in storage devices, and storing control metadata in flash-memory systems which handle some page-specific metadata types (e.g. the read reference voltages) as if they are block-specific, while at the same time not sacrificing the accuracy of the metadata values used by the FMS. It is important to note that one may attempt to approximate the metadata values of all pages in a block by keeping only the value related to one page of the block, and using the value as an approximation for all other pages of the same block. But as explained above, there is no guarantee that all pages of the block will have similar value of the metadata, and thus the accuracy of the metadata is compromised.